fix(web): scope /api/workflows AI rate limit to the start (POST), not status polls - #1524
fix(web): scope /api/workflows AI rate limit to the start (POST), not status polls#1524groupthinking wants to merge 1 commit into
Conversation
… polls The video-to-actions status poll (GET /api/workflows/.../:runId) fires every ~1.5s (studio-workflow.ts), but /api/workflows was blanket-listed as an AI route (12/min). After ~11 polls the client exhausted the AI budget and was 429'd mid-run; getVideoToActionsStatus treats 429 as non-terminal, so pollVideoToActions burned all 20 attempts and the UI hung on "still running". The poll also starved the shared ai:<ip> bucket used by /api/chat, /api/pipeline. Classify /api/workflows by method instead of a blanket prefix: POST (start = real AI work) keeps the 12/min AI budget; GET (status poll) uses the 60/min general budget. Adds proxy-rate-limit-classification.test.ts. Addresses PR #1507 review (VADE logic finding). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
Important Review skippedAuto reviews are limited based on label configuration. 🏷️ Required labels (at least one) (1)
Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Repository YAML (base), Repository UI (inherited), Organization UI (inherited) Review profile: ASSERTIVE Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Dependency Review✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.Snapshot WarningsEnsure that dependencies are being submitted on PR branches and consider enabling retry-on-snapshot-warnings. See the documentation for more information and troubleshooting advice. Scanned FilesNone |
Reconciliation: #1518 merged the same fix — this one needs a decision, and one piece of it is worth keepingWe independently fixed the same defect. #1518 merged as This PR will not apply cleanly any moreBoth hunks target lines that no longer exist. #1518 moved Where the merged version differs, and why
Two of those are worth being concrete about:
The poll retune isn't cosmetic. Fixing only the classifier moves the poller from 40/min under a 12/min ceiling to 40/min under a 60/min one. That clears, but leaves ~20 req/min for everything else the Studio page does on the shared What this PR has that
|
|
Closing as superseded by #1518 (merged on #1524 and #1518 both stop No further action on this branch. |
Pull request was closed
Problem (live on
main)The durable video-to-actions status poll —
GET /api/workflows/video-to-actions/:runId— fires every ~1.5s (20 attempts,studio-workflow.ts). But/api/workflowswas blanket-listed inAI_ROUTE_PREFIXES(proxy.ts), so every poll drew from the strict AI budget (12/min) on the sharedai:<ip>bucket.Consequence: after ~11 polls (~16s) the client is 429'd mid-run.
getVideoToActionsStatustreats a 429 as non-terminal (not 404, norunStatus), sopollVideoToActionsnever breaks early — it burns all 20 attempts and the UI hangs on "still running". The polling also starves the sameai:<ip>bucket used by/api/chat,/api/pipeline, etc.Flagged by the Vercel Agent (VADE) reviewer on #1507 (merged before the fix landed); this is the follow-up.
Fix
Classify
/api/workflowsby method instead of a blanket prefix:A single run's ~20 polls/30s sits comfortably under the general limit, and the expensive start stays protected.
Tests
New
apps/web/src/__tests__/proxy-rate-limit-classification.test.ts(4 cases), asserting the applied budget via theX-RateLimit-Limitheader:60(was12before the fix — the regression guard)12/api/chat) →12regardless of method60Existing
proxy-auth-gate+auth-paths+studio-workflowsuites still pass;tsc --noEmitand ESLint clean on the changed files.Refs #1507 (VADE logic finding).
🤖 Generated with Claude Code